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EXECUTIVE  SUMMARY 


Relying  on  autonomous  underwater  vehicles  (AUVs)  for  ferrying  data  in  an  underwater  network  is  an 
appealing  approach  for  supporting  a  wide  range  of  underwater  networking  applications.  By  equipping 
AUVs  with  short-range,  high-bandwidth  underwater  wireless  communications,  which  feature  lower 
energy-per-bit  cost  than  acoustic  communications,  the  energy-usage  efficiency  and  data  throughput  of  a 
network  servicing  data-intensive  applications  can  be  significantly  improved.  Although  data-ferrying  is  an 
attractive  concept  due  to  its  simplicity,  bringing  this  networking  paradigm  to  fruition  requires  synergistic 
integration  of  a  wide  range  of  technologies  that  go  beyond  networking  to  incorporate,  among  others,  energy 
recharging  and  management,  and  AUV  path-planning  and  navigation.  This  report  outlines  functional  layers 
that  arc  necessary  to  accomplish  the  vision  of  a  cohesive  mobility-driven  underwater  networking 
architecture.  Our  focus  is  on  networking  functionalities,  AUV  path-planning  algorithms,  and  estimation 
and  forecasting  tools  required  to  develop  effective  network  management  and  monitoring  mechanisms. 
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Figures 


1 .  Illustration  of  a  data  collection  system  with  100  nodes.  Each  node  has  10  MB  of  data 
that  must  be  gathered  at  the  FC  for  retrieval,  (a)  Topology  of  a  fixed  underwater  acous¬ 
tic  network  used  to  move  all  data  towards  the  FC  as  described  in  Section  2.1.  The 
shortest-path  tree  T  rooted  at  the  FC  is  shown  (in  dashed  red  lines)  overlaid  over  all 
available  acoustic  links  (shown  in  solid  gray).  This  figure  also  shows  the  partitioning, 
illustrated  by  the  node  color,  of  the  sensing  nodes  into  5  groups  as  described  in  Section 
2.2.  Each  cluster  is  served  by  an  AUV  that  collects  all  data  from  the  sensing  nodes. 
Radial  sectors,  with  central  angle  of  72°,  centered  at  the  FC  were  used  to  defined  the 
partitioning,  (b)  Summary  of  transmitted  data  and  energy  consumption  per  node  after 
all  data  have  been  gathered  at  the  FC  through  the  acoustic  network  as  described  in 
Section  2.1 .  Red  and  green  circles  correspond  to  highlighted  red  and  green  nodes  in  (a).  5 

2.  Network  model  considered  by  MobArch.  Each  subnetwork  (cloud  icons)  has  an  as¬ 
sociated  gateway  node  (green  triangles)  that  funnels  all  data  leaving  and  entering  the 
subnetwork.  AUVs  (blue  spheres)  ferry  data  between  subnetworks  and  periodically 


recharge  their  batteries  at  the  depots  (gold  pentagons).  Gateways  form  a  connected 

acoustic  network  that  defines  the  acoustic  backbone  of  MobArch .  6 

3.  Main  functional  layers  of  MobArch  and  their  correspondence  to  high-level  functionalities 

defined  in  the  classical  OSI  model .  8 


4.  Sample  functionality  of  the  Networking  Layer.  A2  collects  all  data  from  G2  that  are 

addressed  to  G8,  G7,  and  G9.  It  also  downloads  to  G2  all  data  in  its  buffer  that  are 
addressed  to  G3,  G4,  and  G5.  Since  A3  will  visit  G2,  A3  may  be  able  to  pick  up  those 
data  from  G2  and  deliver  them  to  their  destination.  Al’s  buffer  is  full;  thus,  it  can  only 
deliver  data.  G9  is  overflowing.  It  uses  the  acoustic  backbone  (shown  in  Figure  2) 
to  request  an  AUV  visit  sooner  than  it  is  currently  planned.  Since  the  data-storage 
buffer  of  A1  is  full,  it  is  decided  that  A2  should  modify  its  planned  route  and  visit  G9 
directly  after  leaving  G2,  before  visiting  G7  and  G8.  Meanwhile,  G9  uses  its  local 
buffer-management  policy  to  discard  low-priority  and  outdated  data  first .  9 

5.  Illustration  of  an  information  request  triggered  by  the  dynamic  AUV  Path-Planning  Layer. 

It  occurs  as  soon  as  A2  completes  its  data  exchange  with  G2  and  is  ready  to  be  routed. 

G2  can  broadcast  a  request  for  control  data,  or  send  a  multicast  message  to  neighbor¬ 
ing  gateways  and  depots  only.  Although  control  data  from  other  parts  of  the  network 
are  also  relevant,  it  is  not  necessary  to  collect  them  at  G2.  Instead,  the  AUV  Path- 
Planning  Layer  relies  on  the  networkwide  estimation  and  forecasting  tools  provided  by 
the  Monitoring  Layer  to  estimate  and  forecast  necessary  network  metrics.  Since  AUVs 
en  route  may  not  be  reachable  through  the  acoustic  backbone,  all  information  requests 

are  addressed  to  gateways  and  depots  only .  1 1 
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1.  INTRODUCTION 


Renewed  interest  in  the  undersea  domain,  sparked  by  applications  including  environmental  monitoring, 
deep-sea  exploration  and  exploitation,  and  undersea  surveillance  [1],  has  triggered  the  emergence  of  a  new 
generation  of  undersea  systems.  These  systems  feature  enhanced  sensing  and  actuation  technologies  that 
allow  them  to  gather  large  volumes  of  data,  ranging  from  acoustic  and  environmental  measurements  to 
high-resolution  imagery  and  video.  Although  they  are  equipped  with  enhanced  wireless  communication 
technologies,  establishing  reliable  communications  with  these  systems  while  they  are  deployed  remains  a 
challenge.  Nevertheless,  netted  and  seamless  operation  among  them  and  between  them  and  their  operators 
arc  paramount  to  cope  with  the  vastness  of  typical  undersea  operating  areas  and  increasing  demand  for 
undersea  data. 

Underwater  acoustic  networks  epitomize  the  current  networking  paradigm  envisioned  for  the  undersea. 
Acoustic  communications  (ACOMMs)  enable  long-range,  low-bandwidth  communications  and,  thus,  make 
it  possible  for  sparsely  deployed  systems  to  communicate.  Although  popular,  underwater  ACOMMs  face 
formidable  challenges  that  limit  their  capabilities  and  demand  specialized  protocols.  They  suffer  from 
significant  transmission  path  losses  at  high  frequencies,  long  propagation  delays,  low  and 
distance-dependent  bandwidth,  time- varying  multi-path  propagation,  long  interference  ranges,  and 
significant  Doppler  effects  [2],  Furthermore,  acoustic  transmitters  require  properly  designed  media  access 
control  (MAC)  protocols  able  to  mitigate  acoustic  interference.  Even  when  the  latency  and  reliability  level 
of  ACOMMs  are  tolerable,  their  hefty  energy-per-bit  cost  quickly  renders  them  unaffordable  for  most 
battery-powered  undersea  systems  attempting  to  transmit  large  volumes  of  data. 

The  prevailing  paradigms  for  communicating  with,  and  retrieving  data  from,  undersea  systems  arc  based 
on: 

•  physical  recovery,  and 

•  a  combination  of  data  preprocessing,  data  compression,  and  either  tethering  to  a  surface  buoy  able 
to  use  radio  frequency  (RF)  communications  or  using  undersea  ACOMMs  to  transmit  the  data. 

These  methods  suffer  several  shortcomings  from  various  financial,  infrastructure,  and  communication 
perspectives.  Physical  retrieval  of  the  systems  is  maximally  efficient  in  terms  of  energy  used  for 
communications.  However,  its  associated  cost,  demand  for  specialized  recovery  infrastructure,  and  the 
inherent  disconnectedness  of  the  system  throughout  the  entirety  of  its  mission  render  this  approach 
inadequate  for  many  applications.  Data  preprocessing  and  compression  caters  to  improved  connectivity 
when  using  ACOMMs  or  RF  communications  through  a  surface  buoy,  but  continues  to  be  confronted  by 
the  communications-related  energy  consumption.  Moreover,  in  many  situations  buoys  must  be  submerged 
to  avoid  interfering  with  maritime  traffic,  thereby  adding  the  buoy  surfacing  system  and  its  associated 
energy  usage  to  the  overall  system  infrastructure  and  energy  requirements.  Prompt  access  to  undersea  data, 
enhanced  cooperation  among  undersea  systems,  and  the  extended  operational  lifetimes  envisioned  for 
future  undersea  missions  further  challenge  the  aforementioned  paradigms  and  demand  an  enhanced 
underwater  networking  architecture. 

The  advent  of  short-range,  high-bandwidth  underwater  wireless  modes  of  communications  coupled  with 
enhanced  autonomous  underwater  vehicle  (AUV)  technologies  has  given  rise  to  a  mobility-driven 
underwater  networking  paradigm  [3],  [4],  In  this  paradigm,  battery-powered  AUVs  acting  as  data  ferries 
visit  each  network  node  (undersea  system)  and  use  high-bandwidth  underwater  wireless  communications 
for  uploading  (downloading)  data  from  (to)  them.  High-bandwidth  underwater  wireless  communications, 
including  free-space  optical  communications  (OCOMMs)  [5],  magnetic  induction  (MI)  [6],  and  underwater 
RF  communications  [7],  feature  lower  energy-per-bit  cost  than  ACOMMs  at  short  ranges  and,  thus,  can 
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reduce  the  energy  consumption  of  the  overall  undersea  network.  Moreover,  they  enable  netting  systems 
located  in  areas  where  using  ACOMMs  alone  has  traditionally  been  problematic,  such  as  shallow  waters 
and  surf  zones  (5-  to  10-m  depth)  [6],  [7],  An  added  benefit  of  this  paradigm  is  that  interference  among 
undersea  systems  located  even  few  meters  away  from  each  other  is  practically  nonexistent  due  to  the  high 
attenuation  that  OCOMMs,  MI,  and  RF  signals  experience  underwater.  Multiple  transmitter-receiver  pairs 
can  transmit  simultaneously  and  in  close  proximity  without  causing  significant  interference  among 
themselves.  The  bulk  of  energy  consumption  for  the  network,  which  includes  the  undersea  systems  and  the 
AUVs,  is  due  to  the  AUVs’  propulsion  system.  Thus,  for  a  successful  implementation  of  this  paradigm  it  is 
paramount  to  consider  how  to  route  the  AUVs,  and  where  and  when  to  recharge  the  AUV  batteries  so  as  to 
optimize  their  energy  usage,  specially  since  their  recharge  times  are  lengthy.  From  a  network  management 
perspective,  recharging  the  AUV  batteries  leads  to  a  dynamic  network  featuring  a  variable  number  of 
AUVs  available  to  ferry  data. 

The  contribution  of  this  work  is  to  propose  a  cohesive  mobility-driven  underwater  networking 
architecture  (MobArch)  that  captures  unique  aspects  of  the  implementation  of  the  mobility-driven 
networking  paradigm  as  a  viable  underwater  networking  solution.  We  do  not  intend  to  provide  a  complete 
design  and  performance  evaluation  of  a  specific  architecture  for  MobArch.  but  rather  to  discuss  by  example 
the  major  challenges  and  tradeoffs  of  designing  such  an  architecture.  MobArch  features  dynamic  data 
routing  and  AUV  path-planning  algorithms  able  to  cope  with  the  dynamic  nature  of  the  network  and  the 
undersea  environment.  A  successful  implementation  of  MobArch  relies  on  the  availability  and  affordability 
of  reliable  technologies  that  support  AUV  battery  recharging  stations,  AUV  navigation  and  docking 
systems,  underwater  acoustic  networking,  and  point-to-point  high-bandwidth  underwater  wireless 
communications.  While  it  requires  a  cross-layer  design  approach,  our  presentation  emphasizes  aspects  of 
MobArch  germane  to  the  Network  and  Transport  layers  of  the  Open  Systems  Interconnection  (OSI)  model. 
Specific  technology  requirements  are  mentioned  as  required.  Before  introducing  MobArch,  the  benefits  of 
using  a  mobility-driven  paradigm  for  networking  are  illustrated  through  an  example. 


2 


2.  BENEFITS  OF  NODE  MOBILITY  -  A  SAMPLE  CASE 

This  section  illustrates  the  benefits  of  using  node  mobility  for  underwater  data  collection  through  a 
simplified  scenario.  Admittedly,  many  challenges  associated  with  a  real  implementation  of  the  ensuing 
scenarios  arc  disregarded  to  simplify  the  discussion.  Nevertheless,  considerations  about  deployment  cost, 
maturity  of  OCOMM  technologies,  reliability  of  AUV  navigation,  and  efficiency  of  undersea  energy 
transfer  also  drive  the  selection  of  the  most  appropriate  data  collection  approach  for  any  practical  scenario. 

Assume  that  multiple  battery-powered  sensing  nodes  arc  deployed  to  collect  undersea  data.  All  data 
must  be  retrieved  through  a  high-speed  access  point,  hereafter  named  fusion  center  (FC).  Figure  la 
illustrates  the  underwater  data  collection  system  considered  here.  It  comprises  100  nodes  randomly  located 
over  a  34  km  x  34  km  square-shaped  area  with  the  FC  located  in  its  center.  Each  sensing  node  has  a  fixed 
data  payload  of  10  MB.  The  goal  of  the  system  is  to  gather  all  data  to  the  FC  for  retrieval.  The  next  two 
subsections  illustrate  the  performance  level  achievable  when  using  two  different  networking  paradigms. 

2.1  DATA  RETRIEVAL  WITH  A  STATIC  UNDERWATER  ACOUSTIC  NETWORK 

In  this  scenario,  it  is  assumed  that  the  sensing  nodes  form  a  connected  acoustic  network.  Thus,  there 
exists  a  path  connecting  the  FC  to  every  network  node.  For  the  network  topology  illustrated  in  Figure  la, 
this  is  accomplished  by  presuming  the  availability  of  ACOMM  links  able  to  support  transmission  ranges  up 
to  5  km.  At  a  nominal  transmission  rate  of  5,000  bps,  transmitting  the  data  payload  over  a  single  acoustic 
link  requires  roughly  4.4  hrs.  Acoustic  modems  such  as  the  Teledyne  Benthos  920  Series1,  the  LinkQuest 
UWM100002,  and  the  EvoLogics  S2C  R  12/243  can  support  these  data  rate  and  range  requirements.  Using 
40  W  as  a  nominal  acoustic  transmission  power,  it  follows  that  the  associated  price-per-bit  of  ACOMMs  is 
2.216  /iWh/bit  and  the  overall  energy  consumption  to  transmit  10  MB  of  data  is  177.28  Wh. 

FC  relies  on  a  shortest-path  tree  T  rooted  at  the  FC  to  gather  all  data  (see  Figure  la).  The  tree  T  is  a 
spanning  tree,  that  is,  the  distance  from  the  FC  to  any  node  v  €  T  is  a  geodesic  between  the  FC  and  v  over 
the  acoustic  network.  Due  to  the  long-range  propagation  of  acoustics  and  since  the  communication 
medium  is  shared  by  all  nodes,  a  MAC  protocol  must  be  used  to  mitigate  interference  and  data  losses  due 
to  collisions  when  transmitting  the  data  towards  the  FC.  However,  including  such  a  MAC  protocol  would 
compound  our  analysis  of  energy  usage  and  data  latency.  In  practice,  data  retransmissions  due  to  packet 
errors  and  collisions,  and  the  usage  of  a  MAC  protocol  will  cause  the  energy  usage,  data  transmitted,  and 
latency  seen  by  the  FC  to  increase.  Although  useful  for  the  simplified  analysis  presented  in  this  section, 
using  a  spanning  tree  for  routing  data  towards  the  FC  is  neither  necessary  nor  recommended.  Alternative 
data  routing  approaches  for  underwater  acoustic  networks  can  be  found  in  [8] . 

Instead  of  using  a  MAC  protocol,  it  is  assumed  that:  (al)  the  ACOMMs  links  are  error-free,  (a2)  all 
nodes  can  simultaneously  transmit  and  receive  data,  and  (a3)  there  is  no  acoustic  interference  among 
nodes.  One  quickly  realizes  that  nodes  with  lower  depths  in  T  relay  more  data  towards  the  FC  (see  Figure 
lb).  Hence,  they  use  more  energy  for  acoustic  communications  and  deplete  their  batteries  sooner  than  other 
nodes.  For  instance.  Node  24  transmits  its  own  data  and  relays  data  from  41  other  nodes.  It  consumes  7.44 
kWh  on  acoustic  communications  alone.  The  entire  network  consumes  90.06  kWh,  all  of  it  provided  by 
the,  often  non-rechargeable,  batteries  of  the  sensing  nodes.  In  terms  of  data  latency,  gathering  all  data  at  the 
FC  takes  a  staggering  7.78  days.  Due  to  (al)-(a3),  these  performance  values  define  optimistic  lower 

'Benthos  920  Series  ATM  925  supports  data  rates  between  140  and  15,360  bps  at  2-6  km  ranges.  Data  retrieved 
fromhttp://teledynebenthos.com/product/acoustic_modems/920-series-atm-925  on  February  2,  2016. 

‘LinkQuest  UWM10000  supports  data  rates  up  to  5,000  bps  at  ranges  up  to  10  km.  Data  retrieved  from 
http://www.link-quest.com/html/modelsl.htm  on  February  2,  2016. 

3EvoLogics  S2C  R  12/24  supports  data  rates  up  to  9,200  bps  at  ranges  up  to  6  km.  Data  retrieved 
fromhttps://www. evologics.de/en/products/acoustics/s2cr_12_24.html  on  February  2,  2016. 
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bounds  on  the  energy  usage,  data  volumes  transmitted,  and  latency  observed  at  the  FC.  In  a  real  underwater 
acoustic  network  deployment,  it  is  expected  that  all  these  values  will  increase  in  magnitude  according  to 
the  specific  MAC  protocol  used  and  the  bit-error  rates  observed  in  the  acoustic  channel. 

2.2  DATA  RETRIEVAL  USING  AUVS 

Instead  of  using  the  aforementioned  data  collection  framework,  this  section  uses  a  flotilla  of  five  AUVs 
to  collect  all  data  and  deliver  them  to  the  FC.  The  sensing  nodes  arc  partitioned  into  five  clusters.  Each 
cluster  is  assigned  to  an  AUV  for  service.  AUVs  are  launched  from  the  FC  and  use  a  nearest-neighbor  rule 
to  decide  what  node  in  their  assigned  cluster  to  visit  next.  Once  all  nodes  have  been  visited,  each  AUV 
returns  to  the  FC  and  delivers  the  data.  All  nodes  and  AUVs  use  OCOMMs  to  exchange  data. 

For  this  example,  REMUS-6004  AUVs  with  a  5.2-kWh  battery  arc  considered.  Their  mission  duration 
capability  of  up  to  70  hrs  enables  them  to  travel  up  to  388. 1  km  at  a  nominal  speed  of  1.54  m/s  (3  knts). 

The  OCOMMs  system  considered  features  a  bit  rate  of  10  Mbps  at  a  range  of  10  m  and  uses  5  W  of  power 
to  transmit.  Hence,  its  associated  cost-per-bit  is  138.89  pWh/bit.  With  these  characteristics,  OCOMMs 
consume  11.11  mWh  to  upload/download  10  MB  of  data.  The  latency  of  the  data  collection  system 
depends  on  the  AUV  travel  times  and  data  exchange  times.  At  10  Mbps,  it  takes  8  s  to  upload  (download) 
10  MB  of  data  from  (to)  any  node.  The  AUV-cycle  lengths  for  the  node  partition  shown  in  Figure  1  range 
between  65.56  and  92.18  km.  Disregarding  ocean  currents,  an  AUV  moving  at  1.54  m/s  completes  the 
shortest  cycle  in  11.83  hrs  and  the  longest  cycle  in  16.63  hrs,  and  consumes  0.88  and  1.24  kWh, 
respectively.  Thus,  it  takes  16.63  hrs  for  all  the  data  to  arrive  at  the  FC.  Each  AUV  consumes  less  than  25% 
of  its  battery  capacity  when  collecting  data  from  its  assigned  set  of  nodes.  The  entire  system  consumes 
5.26  kWh,  nearly  all  of  it  provided  by  the  rechargeable  batteries  of  the  AUVs.  In  this  case  each  AUV  can 
complete  its  cycle  without  recharging  its  battery.  When  ACOMMs  alone  were  used  to  collect  the  data,  two 
nodes  needed  battery  capacities  larger  than  5.2  kWh  to  satisfy  the  energy  requirements  of  their  own 
ACOMMs. 

Different  from  the  scenario  described  in  the  previous  section,  increasing  the  amount  of  data  to  be 
collected  per  node  does  not  significantly  impact  the  overall  energy  consumption  and  latency  of  the  system. 
Here,  the  latency  and  energy  consumption  due  to  OCOMMs  are  dominated  by  the  AUV  travel  times  and 
AUVs’  energy  consumption  associated  to  their  propulsion  systems.  Ocean  currents  will  impact  AUV 
energy  consumption  and  should  be  carefully  considered  when  selecting  AUV  trajectories. 


4The  REMUS  600  features  a  5.2  kWh  rechargeable  lithium  ion  battery,  supports  speeds  of  up  to  2.6  m/s  (5  knts),  and  can  yield 
up  to  70  hrs  of  endurance.  Data  retrieved  front  REMUS  600  Autonomous  Underwater  Vehicle  at  http://www.km.kongsberg.com  on 
February  2,  2016. 
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(a) 


(b) 


Figure  1 .  Illustration  of  a  data  collection  system  with  1 00  nodes.  Each  node  has  1 0  MB  of  data  that 
must  be  gathered  at  the  FC  for  retrieval,  (a)  Topology  of  a  fixed  underwater  acoustic  network  used 
to  move  all  data  towards  the  FC  as  described  in  Section  2.1.  The  shortest-path  tree  T  rooted  at  the 
FC  is  shown  (in  dashed  red  lines)  overlaid  over  all  available  acoustic  links  (shown  in  solid  gray).  This 
figure  also  shows  the  partitioning,  illustrated  by  the  node  color,  of  the  sensing  nodes  into  5  groups 
as  described  in  Section  2.2.  Each  cluster  is  served  by  an  AUV  that  collects  all  data  from  the  sensing 
nodes.  Radial  sectors,  with  central  angle  of  72°,  centered  at  the  FC  were  used  to  defined  the 
partitioning,  (b)  Summary  of  transmitted  data  and  energy  consumption  per  node  after  all  data  have 
been  gathered  at  the  FC  through  the  acoustic  network  as  described  in  Section  2.1 .  Red  and  green 
circles  correspond  to  highlighted  red  and  green  nodes  in  (a). 
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3.  MOBARCH’S  PHYSICAL  REQUIREMENTS 


Motivated  by  the  example  presented  in  the  previous  section,  this  section  develops  the  rationale  for 
MobArch,  and  introduces  its  physical  building  blocks  and  supporting  infrastructure  requirements.  The 
ensuing  presentation  underscores  the  physical  blocks  needed  by  MobArch  and  the  technology  challenges 
their  implementation  entails. 

The  idea  of  using  mobile  nodes  as  data  ferries  to  enable  connectivity  in  an  otherwise  disconnected 
network  was  first  introduced  in  the  context  of  disruption-tolerant  networking  (DTN)  [9],  and  was  quickly 
adopted  by  the  underwater  networking  community  [3],  [4].  Despite  its  conceptual  simplicity,  developing 
all  necessary  technologies  to  enable  this  form  of  underwater  networking  has  proven  difficult  in  part  due  to 
the  breadth  of  engineering  disciplines  involved  and  the  challenges  associated  with  deployment  and 
operation  of  undersea  systems.  Works  focusing  on  the  data-retrieval  problem  have  considered  multiple 
AUV  path-planning  problem  formulations  [4].  However,  the  development  of  a  cohesive  networking 
architecture  capturing  the  intertwine  among  data  networking  functionalities,  networkwide  control 
requirements,  and  AUV  path-planning  and  battery-recharging  demands  remains  insufficient. 

MobArch’s  vision  is  to  develop  an  underwater  networking  architecture  that  naturally  integrates  AUV  and 
data  management.  MobArch  comprises  several  building  blocks  as  illustrated  in  Figure  2.  The  overall 
network  is  comprised  by  multiple  disconnected  subnetworks,  where  nodes  in  different  subnetworks  are 
presumed  to  be  disconnected.  Beyond  being  out  of  ACOMMs  range,  this  is  a  valid  assumption  when  the 
volume  of  data  to  be  exchanged  between  nodes  in  different  subnetworks  is  so  large  that  ACOMMs  are 
rendered  impractical.  A  subnetwork  can  even  be  a  singleton  representing  a  high-speed  access  point  to,  e.g., 
an  above-water  RF  network  or  a  fiber  optic  cable.  Each  subnetwork  is  assumed  to  be  connected.  All 
intra-subnetwork  data  traffic  is  handled  through  the  local  communications  infrastructure. 


Legend 


Q 

Subnetwork 

A 

Gateway  node 

CZ5 

AUV 

o 

Depot 

Figure  2.  Network  model  considered  by  MobArch.  Each  subnetwork  (cloud  icons)  has  an 
associated  gateway  node  (green  triangles)  that  funnels  all  data  leaving  and  entering  the 
subnetwork.  AUVs  (blue  spheres)  ferry  data  between  subnetworks  and  periodically  recharge  their 
batteries  at  the  depots  (gold  pentagon).  Gateways  form  a  connected  acoustic  network  that  defines 
the  acoustic  backbone  of  MobArch. 
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Each  subnetwork  has  an  associated  high  data-storage  capacity  node,  known  as  the  gateway.  The  gateway 
behaves  as  a  throwbox  where  data  can  be  stored  for  extended  periods  while  on  their  way  to  their  destination. 
Data  to  be  transmitted  (received)  to  (from)  other  subnetworks  arc  funneled  through  the  gateway.  AUVs  can 
also  drop  data  at  a  gateway  where  they  wait  to  be  advanced  toward  their  destination  by  another  AUV.  It  is 
assumed  that  gateways  arc  able  to  use  both  ACOMMs  and  high-bandwidth,  underwater  wireless 
communications.  Gateways  can  represent  cluster  heads  that  define  a  hierarchical  networking  architecture. 

A  flotilla  of  AUVs  is  used  to  collect  (deliver)  data  from  (to)  the  gateways.  AUVs  arc  equipped  with 
high-speed,  wireless  communication  technology  that  allows  them  to  communicate  with  the  gateways.  They 
also  feature  high  data-storage  capacity  so  that  they  can  collect  and  maintain  data  from  multiple  gateways. 
AUVs  are  battery-powered  and,  thus,  they  need  to  be  periodically  recharged.  To  this  end,  special 
AUV-recharging  nodes  called  depots  arc  also  deployed.  Note  that  MobArch  requires  the  deployment  of 
navigation,  homing,  and  docking  systems  to  enable  AUVs  to  locate,  navigate  toward,  and  possibly  dock  at 
gateways  and  depots. 

Depots  arc  visited  by  AUVs  to  recharge  their  batteries.  They  arc  equipped  with  ACOMMs  and,  for  the 
purpose  of  this  work,  arc  presumed  to  always  be  able  to  satisfy  the  energy  demands  of  the  AUVs. 
Nevertheless,  depots  have  a  finite  number  of  recharging  ports.  Thus,  if  multiple  AUVs  tty  to  concurrently 
recharge  their  battery  at  the  same  depot,  some  of  them  may  have  to  wait  until  a  recharging  port  becomes 
available.  Depots  must  support  homing  and  docking  functionalities  for  AUVs  so  that  battery  recharging 
can  take  place. 

Within  MobArch,  ACOMMs  continue  to  play  a  fundamental  role  as  the  enabler  of  long-range 
connectivity  among  gateways.  Gateways  and  depots  form  a  connected  acoustic  network  which  is  used  for 
collecting  and  disseminating  control  data  from  and  to  the  entire  network.  From  a  networking  vantage  point, 
this  enables  MobArch  to  separate  the  control  and  the  data  planes.  The  control  plane  corresponds  to  the 
acoustic  backbone  network5  comprising  gateways  and  depots.  Similarly,  the  data  plane  corresponds  to  the 
virtual  links  instantiated  by  the  AUVs.  This  separation  enables  the  control  plane  to  use  ACOMMs  to 
disseminate  service  policy  adjustments  to  the  entire  network  and  collect  networkwide  status  data  for 
developing  management  and  monitoring  tools  without  being  affected  by  the  payload  data  volumes.  The 
data  plane  uses  the  AUVs  and  a  high-speed  mode  of  communications  to  transport  large  data  volumes  at 
reduced  energy  and  latency  costs.  Note,  however,  that  such  connectivity  assumption  limits  the  maximum 
separation  possible  among  gateways  which  may  render  MobArch  unsuitable  for  very  sparse  network 
deployments,  and  require  the  deployment  of  acoustic  relays  between  gateways. 


^Backbone  network  refers  to  the  infrastructure  that  connects  all  gateways  and  depots  for  transporting  control  data.  Different 
from  its  traditional  use  in  computer  networks,  it  is  neither  presumed  that  the  backbone  network  features  high-capacity  links  nor  that 
it  will  transport  large  data  volumes. 
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4.  MOBARCH’S  FUNCTIONAL  LAYERS 


A  goal  of  MobArch  is  to  support  large- volume  data  exchanges  among  subnetworks  while  providing  a 
prescribed  quality-of-service  (QoS)  level.  This  goal  demands  the  design  of  networking  protocols,  AUV 
path-planning  algorithms,  and  monitoring  tools  able  to  provide  delivery,  throughput,  and  delay  guarantees 
for  all  network  traffic  while  allowing  some  level  of  management  and  supervision. 

Networking  protocols  within  MobArch  will  be  responsible  for  data  routing  and  gateway  memory 
management.  They  will  rely  on  DTN  technologies  to  provide  end-to-end  (source-gateway  to 
destination-gateway)  delivery  guarantees.  Moreover,  they  can  influence  the  selection  of  the  paths  to  be 
followed  by  AUVs  according  to  network-related  parameters  such  as  data  prioritization  and  memory  usage 
at  both  gateways  and  AUVs.  Likewise,  AUV  paths  can  influence  data-routing  and  gateway-memory 
management  policies.  From  a  management  and  monitoring  perspectives,  one  would  like  to  have  assured 
and  non-interrupted  access  to  all  network  components.  Unfortunately,  collecting  networkwide  state 
information  regularly  is  impractical  due  to  the  disconnected  nature  of  the  environment  and  the  high  cost 
associated  with  collection  of  control  data  through  the  acoustic  backbone  network  featured  by  MobArch. 
However  costly,  some  minimum  level  of  network-state  control  information  needs  to  be  exchanged  to 
capture  the  dynamics  of  the  underlying  communication  network  with  AUV  management  and  operation. 

The  main  functional  layers  of  MobArch  are  illustrated  in  Figure  3.  Although  they  require  a  cross-layer 
design  approach  to  access  the  status  of  AUVs  and  gateways,  their  functionalities  can  be  broadly  associated 
with  those  of  the  OSFs  Network  and  Transport  layers.  The  following  subsections  describe  the  various 
MobArch  layer  functionalities  and  their  interactions.  Note  that  MobArch  does  not  require  specific  Physical 
and  Data  Link  layer  technologies  for  point-to-point  communications. 

MobArch  OSI 


Application 

Presentation 


Monitoring: 

Supports  network-wide  oversight  and  provides 
estimation  and  forecasting  tools 


Point-to-Point  Communications: 

Supports  point-to-point  acoustical,  optical,  Ml,  and 
RF  communication  technologies 


Figure  3.  Main  functional  layers  of  MobArch  and  their  correspondence  to  high-level  functionalities 
defined  in  the  classical  OSI  model. 

4.1  NETWORKING  LAYER 

This  layer  provides  network  and  transport  protocols  to  the  acoustic  backbone.  These  protocols  are 
mindful  of  the  energy  constraints  of  the  gateways.  Thus,  they  are  developed  so  that  excessive  packet 
replication  and  interference  among  gateways  is  avoided.  The  known  topology  of  the  acoustic  backbone  can 
be  exploited  to  develop  advanced  routing  algorithms  [8].  Likewise,  using  advanced  MAC  protocols  can 
improve  control-data  throughput  and  reduce  data  latency  in  the  acoustic  backbone  [10]. 


Session 

Transport 

Network 


Data  Link 
Physical 


The  Networking  Layer  also  defines  the  routing  of  the  network  data  through  the  links  instantiated  by  the 
AUVs.  As  illustrated  by  Figure  4,  the  path  followed  by  an  AUV  may  not  reach  the  gateway  to  which  some 
of  its  data  payload  is  routed.  In  this  case,  the  AUV  relays  that  portion  of  its  data  payload  to  an  intermediate 
gateway  where  they  are  temporarily  stored.  Eventually  another  AUV  will  pick  up  the  data  and  advance 
them  towards  their  destination.  Packet  routing  technologies  developed  for  DTN  can  be  leveraged  to  enable 
AUVs  to  establish  routes,  that  is,  virtual  paths,  for  the  data.  These  routes  can  be  designed  bearing  in  mind 
latency-minimization  and  throughput-maximization  objectives  depending  on  the  underlying  applications 
running  on  the  network. 

Protocols  for  data  prioritization  and  storage-queue  management  at  the  gateways  are  also  managed  by  this 
layer.  When  a  gateway  faces  a  data  overflow,  data  priorities  and  time-to-live  scores  can  be  used  as  a  metric 
for  a  queue-management  policy  that,  in  the  same  spirit  of  MaxProp  [9],  judiciously  discards  outdated  and 
low-priority  data  first.  Similarly,  data  priorities  and  gateway  storage-queue  metrics  can  be  used  to 
dynamically  influence  the  AUV  path-planning  algorithms.  They  will,  for  example,  steer  AUV  routes 
towards  regions  in  which  larger  volumes  of  data  need  transport. 


Figure  4.  Sample  functionality  of  the  Networking  Layer.  A2  collects  all  data  from  G2  that  are 
addressed  to  G8,  G7,  and  G9.  It  also  downloads  to  G2  all  data  in  its  buffer  that  are  addressed  to 
G3,  G4,  and  G5.  Since  A3  will  visit  G2,  A3  may  be  able  to  pick  up  those  data  from  G2  and  deliver 
them  to  their  destination.  A1  ’s  buffer  is  full;  thus,  it  can  only  deliver  data.  G9  is  overflowing.  It  uses 
the  acoustic  backbone  (shown  in  Figure  2)  to  request  an  AUV  visit  sooner  than  it  is  currently 
planned.  Since  the  data-storage  buffer  of  A1  is  full,  it  is  decided  that  A2  should  modify  its  planned 
route  and  visit  G9  directly  after  leaving  G2,  before  visiting  G7  and  G8.  Meanwhile,  G9  uses  its  local 
buffer-management  policy  to  discard  low-priority  and  outdated  data  first. 


9 


Lastly,  this  layer  is  also  responsible  for  protocols  to  efficiently  broadcast,  multicast,  anycast,  and  geocast 
data.  Here,  higher  efficiency  is  achieved  by  protocols  that  reduce  the  number  of  copies  of  the  data  that  arc 
propagated  through  the  network,  and  the  corresponding  bandwidth  and  energy  resources  used  in  doing  so. 
AUVs  will  be  the  custodians  of  the  data  and  will  decide  when  and  where  to  replicate  them.  Properly 
designed  multicast  protocols  will  reduce  the  overall  communication  load  of  the  network  when,  for 
example,  updating  the  firmware  of  a  set  of  sensors,  remotely  activating  multiple  underwater  nodes,  and 
delivering  updated  navigation  or  tasking  information  to  a  group  of  nodes. 

4.2  AUV  PATH-PLANNING  LAYER 

This  layer  deals  with  the  problem  of  AUV  path  planning  for  ferrying  data  across  the  network,  which  is 
related  to  the  celebrated  vehicle  routing  problem  (VRP)  [1 1],  Since  VRP  is  known  to  be  an  NP-hard 
problem,  a  plethora  of  heuristics  have  been  developed  within  the  area  of  operational  research  to  solve  it, 
see  [1 1],  [12]  and  references  therein.  The  underwater  mobility-driven  networking  paradigm  considered  by 
Mob  Arch  brings  new  challenges.  AUVs  must  collect  and  deliver  data  from  multiple  gateways  while  being 
aware  of  their  own  data-storage  and  energy  constraints.  Moreover,  they  should  do  so  while  facing  limited 
connectivity  to  the  acoustic  backbone  and  responding  to  the  underlying  dynamics  of  the  network  and  the 
environment.  The  latter  includes  changing  data  priorities  and  QoS  requirements,  varying  ocean  currents 
affecting  AUV  energy  consumption  and  travel  times,  and  network  infrastructure  changes  due  to  node 
failures  and  battery-recharge  times. 

Fixed  data-ferrying  paths  can  be  chosen  by  leveraging  tools  developed  for  the  traveling  salesman 
problem  and  its  manifold  multi-agent  extensions  [4].  Although  appealing  because  they  lead  to  reduced 
control-data  exchanges  and  allow  gateways  to  depend  on  scheduling  strategies  for  ferrying  data  and 
designing  their  local  queue-management  policies,  these  approaches  fail  to  respond  to  the  underlying 
network  dynamics.  In  fact,  they  disregard  QoS  provisioning  to  the  network,  which  goes  beyond  facilitating 
network  connectivity.  Moreover,  most  of  these  approaches  are  episodic  and  presume  that  fixed  data 
volumes  arc  periodically  collected  per  node.  In  the  context  of  Mob  Arch  data  arrive  to  the  gateways  at  rates 
that  feature  spatiotemporal  variability,  thus  rendering  fixed  data-ferrying  paths  inadequate. 

A  suitable  solution  for  AUV  path-planning  captures  the  dynamics  of  the  AUV-battery  energy  levels,  the 
AUV-battery  recharge  times,  and  the  data-storage  capacity  limits  of  the  AUVs  and  the  gateways.  Moreover, 
it  interacts  with  the  Networking  and  Monitoring  Layers  so  as  to  responds  to  dynamic  network  demands,  as 
illustrated  by  Figures  4  and  5,  and  judiciously  plans  how  to  assign  AUVs  to  depots  for  battery  recharge  so 
as  to  avoid  long  queue-waiting  times.  The  AUV  Path-Planning  Layer  also  influences  the  Networking  Layer 
by  providing  AUV-route  estimates  which  can  be  used  for  routing  data  along  multiple  gateway  hops. 
Dynamic  AUV  path-planning  approaches  that  consider  energy  consumption,  data  losses,  and  latency  in  the 
context  of  underwater  data  retrieval  have  been  recently  developed  in  [13,  [14], 

Enabling  dynamic  AUV  path-planning  demands  a  minimum  level  of  coordination  across  the  entire 
network,  which  can  be  achieved  through  the  acoustic  backbone.  Despite  the  bandwidth  and  latency 
challenges  associated  to  ACOMMs,  the  sporadic  frequency  with  which  AUVs  visit  gateways  and  depots, 
and  the  relative  “long”  (for  acoustic  signal  propagation)  AUV  travel-times  between  them  allows  enough 
time  for  collecting  all  control-data  required,  making  a  routing  decision,  and  delivering  that  decision  back  to 
the  AUVs  [13]. 

4.3  MONITORING  LAYER 

This  layer  delivers  management  and  monitoring  tools  for  the  entire  network.  It  serves  as  a  supporting 
layer  for  both  the  Networking  and  the  AUV  Path-Planning  Layers  by  enabling  them  to  capitalize  on  a 
global  view  of  the  network  to,  e.g.,  make  data-routing  decisions.  Ideally,  one  would  like  to  measure  the 
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network-state  everywhere  and  distribute  that  information  so  as  to  make  fully  informed  decisions  regarding 
network  operation.  However,  transmitting  all  this  information  through  the  acoustic  backbone  is  impractical. 

A  similar  challenge  has  been  faced  by  IP  networks  for  which  acquiring  networkwide  status  indicators 
quickly  becomes  a  formidable  task  as  the  network  size  grows.  Instead  of  measuring  everywhere, 
approaches  using  only  a  subset  of  network-measurements  to  predict  the  networkwide  status  have  been 
proposed,  see  [15]  and  references  therein.  These  tools  can  be  leveraged  by  network  operators  who  are 
interested  in  estimating  and  forecasting  metrics  such  as  the  amount  of  data  expected  at  each  gateway, 
data-delivery  latencies,  gateway  energy  usage,  and  data  losses  due  to  buffer  overflows. 

The  resulting  estimation  algorithms  capitalize  on  the  underlying  network  structure  given  by  the  data 
routes  and  AUV  paths  defined  by  the  Networking  and  AUV  Path-Planning  Layers,  respectively.  Collecting 
a  subset  of  measurements  for  evaluating  the  network-status  estimators  can  be  done  on  demand,  that  is, 
triggered  in  response  to  a  monitoring  request  or  by  a  protocol  in  the  Networking  and  AUV  Path-Planning 
Layers  (cf.,  Figure  5).  Network  operators  can  also  use  these  measurements  for  constructing  forecasting 
models.  A  related  alternative  bestows  each  gateway  with  the  responsibility  of  maintaining  local  forecasting 
models. 


for  information 


Optional  response 

\ 


Figure  5.  Illustration  of  an  information  request  triggered  by  the  dynamic  AUV  Path-Planning  Layer.  It 
occurs  as  soon  as  A2  completes  its  data  exchange  with  G2  and  is  ready  to  be  routed.  G2  can 
broadcast  a  request  for  control  data,  or  send  a  multicast  message  to  neighboring  gateways  and 
depots  only.  Although  control  data  from  other  parts  of  the  network  are  also  relevant,  it  is  not 
necessary  to  collect  them  at  G2.  Instead,  the  AUV  Path-Planning  Layer  relies  on  the  networkwide 
estimation  and  forecasting  tools  provided  by  the  Monitoring  Layer  to  estimate  and  forecast 
necessary  network  metrics.  Since  AUVs  en  route  may  not  be  reachable  through  the  acoustic 
backbone,  all  information  requests  are  addressed  to  gateways  and  depots  only. 
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Each  gateway  will  use  its  historical  status  data  to  train  parametric  models  able  to  forecast  variables  of 
interest  at  multiple  resolution  levels  so  as  to  enable  reliable  short-term  and  long-term  forecasts.  The 
parameters  defining  this  models  are  periodically  collected  by  the  operator  who  couples  them  with  the 
known  network  topology  to  build  networkwide  forecasting  models. 
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5.  FUTURE  EXTENSIONS  OF  MOBARCH 

Several  research  directions  to  broaden  the  scope  of  MobArch  are  possible.  One  could  remove  the 
acoustic  backbone  requirement  and  have  AUVs  transport  both  control  and  payload  data.  Control  data  is 
now  disseminated  through  the  network  by  AUVs  that  rely  on  gateways  as  intermediate  storage  nodes. 
Although  this  strategy  ensures  that  control  data  eventually  propagate  through  the  network,  their 
propagation  rate  may  be  slow  and  is  tied  to  the  speed  of  the  AUVs.  The  network  would  have  to  rely  heavily 
on  estimation  and  forecasting  tools  provided  by  the  Monitoring  Layer  since  measurements  of  the  current 
network  status  may  not  always  be  available. 

In  this  new  paradigm,  distributed  and  dynamic  AUV  path-planning  functionalities  become  essential  to 
continue  supporting  the  main  services  provided  by  the  AUV  Path-Planning  Layer.  Their  goal  is  to  enable 
AUVs  to  plan  their  paths  based  on  the  information  that  they  acquire  when  visiting  gateways  and  depots 
only.  To  this  end,  AUVs  leverage  tools  provided  by  the  Monitoring  Layer  to  construct  and  maintain 
networkwide  prediction  models  that  can  be  used  for  estimation  and  forecasting  of  networkwide  parameters. 

MobArch  can  also  incorporate  mobile  gateway  nodes  and  subnetworks  in  which  the  role  of  the  gateway 
can  be  performed  by  multiple  nodes.  Each  subnetwork  may  use  a  different  node  as  a  gateway  according  to 
a  locally  defined  schedule  chosen  to  maintain  homogeneous  energy  consumption  among  all  nodes.  In  this 
case,  the  Networking  Layer  must  support  a  gateway-location  discovery  protocol  that  allows  AUVs  to  find 
the  geographical  location  of  the  current  subnetwork  gateway.  ACOMM  exchanges  between  AUVs  and 
subnetwork  nodes  other  than  gateways  become  necessary  for  AUVs  to  learn  the  gateway  identity  and 
location. 
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6.  SUMMARY 


MobArch  was  introduced  in  response  to  the  practical  demands  of  the  mobility-driven  underwater 
networking  paradigm.  Its  architecture  underscores  the  importance  of  judiciously  using  multiple  underwater 
wireless  communication  modes  for  networking,  enabling  dynamic  AUV  path-planning  for  choosing 
data-ferrying  paths,  developing  advanced  networkwide  monitoring  tools,  and  synergistically  integrating 
AUV  and  data  routing.  Although  the  benefits  in  terms  of  energy  usage  and  data  latency  achievable  when 
using  MobArch  can  be  significant,  realizing  the  vision  of  a  mobility-driven  underwater  networking 
paradigm  is  challenging  due  to  the  various  technology  challenges  that  must  be  surmounted.  Nevertheless, 
broad  scientific  interest  in  the  undersea  and  ongoing  technology  developments  continue  to  pave  the  way 
towards  accomplishing  the  vision  on  MobArch. 
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